The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Relational database management systems (RDBMSs) store information in tables, where each piece of data is stored at a particular row and column. Information in a given row generally is associated with a particular object, and information in a given column generally relates to a particular category of information. For example, each row of a table may correspond to a particular employee, and the various columns of the table may correspond to employee names, employee social security numbers, and employee salaries.
As is well known, each column of a relational table is associated with a data type, and all information within a particular column is required to conform to the particular column's data type. For example, only numbers can be stored in a column that is associated with the “number” data type.
Extensible Markup Language (XML) provides a convenient way to express information in a hierarchically structured format. XML-formatted information can be stored within a relational table. According to current approaches, any relational table column that stores XML-formatted information in a “native” format, such that the structure of the XML information is preserved, is associated with one of two types: an XMLType(document) type, or an XMLType(content) type. Only XMLType(document) type instances can be stored in an XMLType(document) type column, and only XMLType(content) type instances can be stored in an XMLType(content) type column.
A user retrieves information from and makes updates to a database by interacting with a database application. The user's actions are converted into a query by the database application. The database application submits the query to a database server. The database server responds to the query by accessing the tables specified in the query to determine which information stored in the tables satisfies the query. The information that satisfies the query is retrieved by the database server and transmitted to the database application. Alternatively, a user may request information directly from the database server by constructing and submitting a query directly to the database server using a command line or graphical interface.
Queries submitted to the database server must conform to the syntactical rules of a database query language. One popular database query language, known as the Structured Query Language (SQL), provides users a variety of ways to specify information to be retrieved from relational tables.
Although not necessarily a database query language, a new language for querying information contained in XML documents was recently conceived: XML Query Language (XQuery). XQuery is based on XML, and is described in “XQuery 1.0: An XML Query Language,” W3C Working Draft 29 Oct. 2004. Another related technology, XPath, is described in “XML Path Language (XPath) 2.0,” W3C Working Draft 29 Oct. 2004. XQuery may use XPath for path traversal.
When a SQL query is executed, the results are returned as a row set, which is a set of rows. In contrast, when an XQuery query is executed, the results are returned as an instance of XMLType(sequence) type. In XQuery terminology, the result of an XQuery is an instance of XQuery data model. In SQL/XML terminology, the result of an XQuery is an instance of XMLType(sequence) type.
As described in “XQuery 1.0 and XPath 2.0 Data Model,” W3C Working Draft Oct. 29, 2004, an XML sequence is sequence of items. Each item may be either a node or an atomic value. The entire contents of “XQuery 1.0 and XPath 2.0 Data Model” are incorporated by reference for all purposes as though fully set forth herein.
There are some significant differences between XMLType(sequence) type instances and XMLType(document) type instances or XMLType(content) type instances. Unlike XMLType(document) type instances and XMLType(content) type instances, XMLType(sequence) type instances do not have a multi-tiered hierarchical structure. XMLType(document) type instances and XMLType(content) type instances consist of a document node that is the parent of one or more child nodes, but XMLType(sequence) type instances do not contain such a parent document node. XMLType(sequence) type instances are organizationally “flat.” There is no nested sequence within an XMLType(sequence) type instance. However, each item of the sequence can be a node having hierarchical structures.
Also, unlike XMLType(sequence) type instances, XMLType(document) type instances and XMLType(content) type instances do not allow for the representation of atomic values that are not nodes. Everything within an XMLType(document) type instance or an XMLType(content) type instance is a node of some kind. This is significant, because, for example, if an XQuery query processor were to be asked whether a node is an instance of an atomic value, the query processor would respond negatively. Thus, if XMLType(sequence) type instances are “serialized” into XMLType(content) type instances, important information may be lost in translation.
Although at least one currently available RDBMS provides SQL functions to manipulate XMLType(document) type instances and XMLType(content) type instances that are contained in relational tables, these functions are not designed to operate on XMLType(sequence) type instances. Because of the differences between XMLType(sequence) type instances and XMLType(content) type instances, some of which are described above, none of these functions, as they are currently implemented, operates correctly relative to XMLType(sequence) type instances.